As is known, there are contexts where a need exits to check and verify operations performed by an entity, e.g. an administrator, on another entity, e.g., a computer system. For example, in industry outsourcing is an adopted practice and therefore a need exits to control the operations performed by the personnel of the external company to which the job is farmed out and at the same time to guarantee the privacy of the personnel, without however giving up the possibility of verifying and linking, in case of necessity, the operations with the people who performed them.
In a context involving system and network administrators and administered systems and networks, the aforementioned need is generally met by generating a so-called “log file”, which M. Ruffin, A survey of logging uses, Tech. Rep., Dept. of Computer Science, University of Glasgow, Glasgow, Scotland, February 1995. defines as a “plain file where data are stored sequentially as they arrive, by appending them to the end of the file. When a problem arises in the system (e.g. a fault or an intrusion), the log file is re-read to find its source and/or to correct its consequences”.
In many computer applications, sensitive information such as log files must be kept on an untrusted machine. Such information must be protected against attackers, as well as against partially trusted entities to be given partial, but not total, access to the stored information.
US 2003/0212899 discloses a method, an apparatus, and computer instructions for protecting sensitive data in a log file. Data is logged into a file. The data in the log file is in a protected state and the data is never written to the log file in an unprotected fashion. Prior to the data being logged into the file, the data is parsed for specific data meeting predetermined criteria. The specific data is selectively protected with a security measure while leaving a remainder of the log file unprotected by the security measure. The viewer or program used to access the data in the log file is responsible for unprotecting or allowing the data to be viewed if the appropriate key is provided.
Furthermore, U.S. Pat. No. 5,978,475 provides a method and an apparatus for generating a secure audit log using an untrusted machine communicating with a trusted machine over a limited communications channel. Entries are stored in the audit log in sequential order. Each entry in the audit log contains the one-way hash of the previous entry. This enables an auditor to verify that each entry was written into the log after the previous entry and before the subsequent entry. Any attempt to delete entries, add entries, or modify entries in the middle of the log will be immediately noticed because the one-way hash function values will no longer be valid.
Each log entry contains a permission mask, an encrypted file, a (unkeyed) hash value including the encrypted file plus a representation of a previous hash value, and a (keyed) message authentication code (MAC) value that itself authenticates the hash value. The MAC is cryptographically secured with an authentication key derived by hashing an authentication key for a previous log entry; and the (encrypted file is cryptographically secured with an encryption key derived by hashing the authentication key. This makes it possible to give encryption keys for individual log entries to partially-trusted entities, allowing them to read and decrypt files without being able to make undetectable changes. In addition, because both the authentication and encryption keys are session-specific and irreversibly related to their predecessor values (i.e., a current key can be generated from its predecessor, but not vice-versa), an attack on a single entry can not be extended backward through the sequence to change the entire audit trail. This both prevents undetectable attack on a single entry and preserves the security of its predecessors.